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Ada  Transition  Research  Project  (Phase  I) 
Final  Report 


1.0  ABSTRACT: 

In  this  study  we  investigated  several  issues,  methods,  and  tools  that  impact  the  software 
life  cycle  development  that  the  Army  uses  to  design,  implement,  test,  and  maintain  appli¬ 
cation  software.  The  purpose  of  this  project  was  not  only  the  evaluation  of  these  methods 
but  the  identification  of  problems  affecting  the  success  of  software  development  within 
the  constraints  of  current  development  policy.  This  paper  outlines  a  process  for  tran¬ 
sitioning  older  systems  using  current  software  engineering  methodologies. 

The  U.S.  Army  Information  Systems  Engineering  Command  (USAISEC)  maintains  o'-er 
100  Standard  Army  Management  Information  Systems  (ST AMISs).  The  need  has  been 
identified  to  modernize  these  systems.  One  way  is  to  upgrade  these  systems  from  a 
COBOL,  flat  file,  batch  processing  mode  to  systems  written  in  Ada  in  order  to  increase 
functionality,  maintainability,  and  reusability.  While  the  appropriate  technology  exists  for 
this  effort,  no  systematic  knowledge  exists  about  how  to  effectively  and  efficiently  make 
the  transition.  This  lack  of  knowledge  hinders  the  development  of  an  appropriate  transi¬ 
tion  strategy. 


2.0  OBJECTIVE: 

The  objective  of  this  project  was  to  examine  the  application  of  various  tools  and  methods 
to  the  transition  of  existing  STAMIS  applications  from  COBOL  to  systems  written  in  Ada, 
designed  for  re-use,  and  utilizing  newer  technological  capabilities.  Specifically,  this  pro¬ 
ject  examined  the  application  of  reverse  engineering  tools  and  methods,  compared  func¬ 
tional  decomposition  versus  object-oriented  design,  determined  specific  CASE  tool  re¬ 
quirements  for  a  STAMIS  type  environment,  assessed  Ada  training  provided  by  the  De¬ 
partment  of  Defense,  and  established  a  framework  for  examining  the  maintainability/re¬ 
usability  of  code. 

Upon  completion  of  the  re-designed  system,  run  time  parameters  and  functionality  will 
be  compared  to  the  existing  system.  The  tasks  completed  under  the  project  include: 
evaluation  of  CASE  (Computer-aided  Software  Engineering)  tools;  reverse  engineering 
a  STAMIS  to  create  a  high  level  description  of  its  functionality;  redesign  of  the  system 
using  object-oriented  and  functional  decomposition  methods;  and  analysis/comparison  of 
design  approaches. 
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3.0  APPROACH: 


AIRMICS  (Army  Institute  for  Research  in  Management  Information,  Communications, 
and  Computer  Sciences)  in  conjunction  with  SDC-A  (Software  Development  Center-At- 
lanta)  selected  the  Installation  Material  Condition  Status  Reporting  System  (IMCSRS),  an 
operational  STAMIS  written  in  COBOL,  to  re-engineer  and  redesign  using  both  functional 
decomposition  and  object-oriented  design  methods. 

Two  key  issues  for  an  initial  transition  effort  include  the  selection  of  an  appropriate  sys¬ 
tem  and  the  selection  of  appropriate  personnel.  Many  development  problems  were 
avoided  by  selecting  a  system  that  was  not  extremely  complex,  involved  few  interfaces, 
had  a  reasonable  number  of  lines  of  code,  decent  documentation,  etc..  The  knowledge 
and  confidence  acquired  during  the  initial  ”Proof-of-Principle”  effort  can  be  used  for 
future  systems  development. 


3.1.  Hardware  Environment: 

The  hardware  selection  decision  for  this  transition  effort  was  based  in  pan  on  the  soft¬ 
ware  tools  selected  -  certain  tools  only  run  on  certain  platforms.  The  basic  premise  is  - 
do  not  commit  to  a  hardware  platform  until  the  software  tools  have  been  selected.  Since 
the  target  language  was  Ada,  we  were  not  bound  to  a  specific  development  platform. 
Because  one  of  the  strengths  of  Ada  is  portability,  recompilation  should  be  the  only  step 
required  to  port  a  system  implemented  in  Ada  to  the  target  platform.  Another  considera¬ 
tion  in  the  selection  of  hardware  is  that  most  CASE  tools  have  extensive  random  access 
memory  and  secondary  memory  requirements.  In  addition,  a  multi-tasking  windowed 
environment  is  normally  required,  especially  for  the  more  complex  CASE  tools. 


The  hardware  chosen  to  implement  the  analysis  and  re-desiqn  consisted  of  a  SUN  work¬ 
station.  This  machine  was  chosen  not  only  for  its  compatibility  with  the  operating  envi¬ 
ronment  already  in  place  but  also  because  it  supports  the  graphical  user  interface  (GUI) 
necessary  for  building  the  diagrams  using  the  CASE  tools. 

3.2.  Software  Environment 

3.2.1.  Operating  System 

The  system  development  was  done  under  SUN  OS  3.5  with  the  UNIX  4.2  Operating 
system.  Again,  this  choice  was  based  not  only  on  compatibility  but  to  increase  the  port¬ 
ability  of  the  resulting  code. 

3.2.2.  Programming  Language 

An  Alsys  Ada  compiler  was  being  obtained  for  use  in  the  implementation  stage  of  the 
project  for  coding  the  new  system  based  on  the  designs. 

Ada  offers  many  features  not  found  in  other  languages.  It  allows  a  program  to  easily 
interface  the  hardware.  It  also  supports  real  time  programming  and  current  execution  of 
several  program  tasks.  These  features  are  advantageous  for  embedded  weapons  systems. 
However,  such  features  have  limited  value  to  an  MIS  system.  The  main  drawback  of 
using  Ada  for  MIS  system  is  its  very  awkward  and  complex  input/output(I/0)  routines. 
For  example,  in  Pascal  to  print  a  line  of  text  consisting  of  several  different  data  types  on 
the  screen  requires  only  a  single  statement.  In  Ada  each  type  must  have  its  own  I/O 
package  and  separate  statements  are  required  for  each.  This  makes  programming  more 
difficult  and  non-intuitive.  For  programs  which  are  not  involved  in  extensive  I/O  this  is  a 
minor  inconvenience.  However,  for  MIS  systems  where  I/O  is  a  major  portion  of  the 
design,  this  drawback  can  become  formidable. 


3.2.2. 1  Ada  Training  (Course  Critique) 

The  following  sections  contain  a  course  critique  of  Ada  training  taken  by  Major  David 
Stevens  of  AIRMICS  and  Captain  Richard  Wassmuth  of  SDC-A  in  preparation  for  this 
design  effort.  This  extract  of  their  comments  on  the  course  is  submitted  as  an  assessment 
of  the  formalized  Ada  training  being  offered  by  the  Department  of  Defense. 

The  four  weeks  of  training  were  necessary  to  solidify  the  concepts  of  software  design  as 
well  as  the  Ada  language  itself.  The  first  week  covered  basic  language  as  well  as  general 
software  design  concepts.  The  following  two  weeks  were  sufficient  to  learn  the  details  of 


the  language  to  include  packaging,  tasking  and  generics.  The  concepts  were  tested  in  an 
excellent  group  project  assigned  the  last  week.  The  amount  of  time  allowed  was  appropri¬ 
ate  to  cover  the  different  components  of  the  Ada  language. 

The  course  assumes  that  the  student  knows  about  structured  programming,  data  struc¬ 
tures  and  their  associated  algorithms  (stacks,  queues,  linked  lists,  etc  ),  and  other  soft¬ 
ware  engineering  principles.  The  course  takes  a  ’’hands-on”  approach  to  learning  Ada 
with  time  equally  divided  between  the  classroom  and  the  computer  laboratory.  The 
programming  projects  are  designed  to  teach  one  or  two  features  of  the  language  at  a  time. 
This  approach  proved  to  be  an  excellent  methodology  for  those  migrating  to  Ada  from  C 
or  Pascal.  This  was  because  they  possess  many  of  the  same  features.  Those  who  had 
been  programming  in  COBOL  for  many  years  had  a  difficult  time  grasping  such  simple 
concepts  as  passing  parameters  to  a  procedure  or  function.  This  made  it  even  more 
difficult  for  them  to  understand  the  concept  of  tasks  and  object-oriented  programming. 
Students  that  were  not  familiar  with  COBOL  were  for  the  most  part  able  to  master  the 
new  concepts  without  difficulty. 

Lecture,  followed  by  hands-on  exercises  to  demonstrate  the  new  concepts,  was  an  excel¬ 
lent  means  of  teaching  the  language.  This  teaching  method  has  to  be  the  most  significant 
aspect  of  the  class.  While  the  students  complete  the  exercises,  the  instructor  is  available 
to  coach  the  student  through  any  difficulties  they  would  encounter.  Two  organizational 
changes  could  improve  the  overall  training.  The  object-oriented  design  lessons  were 
taught  after  the  language  concepts.  Design  techniques  are  the  most  basic  concepts  that 
must  be  learned  to  create  maintainable  software.  Regardless  of  the  language,  software 
engineering  techniques  must  be  learned  first.  The  student  can  then  look  to  a  specific 
language,  Ada  in  this  case,  for  constructs  that  will  implement  the  design  concepts.  This 
means  of  learning,  leads  to  the  other  change.  The  concepts  of  packages  should  be  taught 
following  the  object-oriented  design  lessons.  Packages  are  the  most  basic  building  blocks 
in  the  Ada  language.  They  provide  for  the  implementation  of  objects  and  collections  of 
operations.  The  packages  should  be  taught  to  be  a  critical  part  of  the  implementation,  not 
just  an  optional  construct. 

The  primary  area  of  weakness  observed  in  the  class  was  the  lack  of  their  ability  to  decom¬ 
pose  a  problem.  Most  programmers  in  the  class  had  a  very  difficult  time  in  conceptualiz¬ 
ing  a  real  world  problem  and  then  translating  it  into  functional  modules  that  would  make 
up  the  final  program.  This  is  clearly  a  major  weakness  in  our  programmers  that  can  have 
a  major  impact  on  the  maintenance  of  future  systems.  This  would  seem  to  imply  that 
even  a  well  designed  system,  can  end  up  as  a  poorly  structured  program  that  is  expensive 
to  maintain. 

It  is  recommended  that  in  addition  to  Ada  training  the  courses  on  problem  solving  be 
given.  A  beginner  course  in  structured  programming  and  algorithms  should  be  a  pre- 
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requisite  to  taking  an  Ada  programming  language  course. 


Overall,  the  training  was  excellent.  However,  Ada  was  designed  to  work  from  a  high 
level  of  understanding  of  the  problem  to  a  more  detailed  level  for  implementation.  Teach 
the  language  in  the  same  manner.  Work  from  a  good  design  to  the  high  level  Ada  con¬ 
structs  of  packages,  subprograms  and  tasks.  Then  teach  the  more  low  level  constructs  of 
the  language  such  as  looping,  assignments  and  data  structures.  Nothing  is  gained  from  a 
powerful  language  without  a  strong  design. 


3.2.3.  CASE/Development  Tools: 

3.2.3. 1.  Overview  of  CASE  (Computer-aided  Software  Engineering)  Tools 

Software  Engineering  is  comprised  of  procedures  (project  tracking,  project  control,  soft¬ 
ware  quality  assurance,  configuration  management,  metrics),  methods  (analysis,  design, 
code,  test),  and  tools  (coding,  analysis,  testing,  project  management,  documentation). 
CASE  includes  various  tools  that  can  partially  automate  portions  of  the  software  develop¬ 
ment  life  cycle.  Initially,  the  tools  were  primarily  software  aids  to  assist  in  the  generation 
of  graphical  representations  of  a  system  (the  representation  form  depends  upon  what 
method  the  specific  tool  supports).  Current  tools  incorporate  other  features  such  as  pro¬ 
ject  management,  requirements  tracking,  code  generation,  etc.  CASE  tools  are  often 
characterized  as  ’’Upper”  or  ’’Lower”  CASE.  Upper  CASE  tools  support  front-end  devel¬ 
opmental  activities  such  as  business  modeling,  requirements  analysis,  entity  relationship 
modeling,  etc.,  while  lower  CASE  tools  support  back-end  stages  such  as  code  restructur¬ 
ing  and  re-engineering. 

Though  various  CASE  tools  perform  well  at  various  stages  of  system  development,  no 
true  full  life  cycle  tool  exists  at  this  time  (though  many  claim  to  do  so).  In  order  for  tools 
to  be  fully  integrated,  two  actions  need  to  be  completed  -  a  common  repository;  and 
translation  mechanisms  from  stage  to  stage,  e.g.  translation  of  data  flow  diagrams  to 
structure  charts.  National  Institute  of  Standards  and  Technology  (NIST)  has  published  the 
Information  Resource  Dictionary  Standard  (IRDS)  which  outlines  the  standard  manner  in 
which  to  organize  information  within  a  repository  as  well  as  the  operations  to  be  sup¬ 
ported  on  the  repository.  The  key  with  the  repository  issue  is  that  NIST  has  developed  a 
standard  which  outlines  the  required  interfaces  to  a  repository.  By  vendors  adhering  to 
the  IRDS  standard,  information  exchange  among  various  CASE  tools  is  made  possible. 


3.2.3.2.  CASE  Evaluation  Criteria: 

Some  of  the  CASE  tool  characteristics  that  were  used  in  evaluating  the  various  products 
that  were  under  consideration  for  this  design  effort  include. 
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functionality 
interfaces 
performance 
time  constraints 

me'^ods  supported  -  data  flow,  process  driven,  data  modeling,  etc. 
data  dictionary 
single,  multi-user 
code  restructuring 

requirements  tracking  (links  features  in  the  application  to  requirements  identi¬ 
fied  in  analysis  and  flags  requirements  for  which  no  feature  exists) 
analysis 
design 

code  generation 
configuration  management 
error  analysis 

automatic  documentation  generation 
cost 

Because  of  the  multitude  of  CASE  products  on  the  market  (each  with  competitive 
strengths  and  weakness),  the  key  in  selection  is  to  determine  at  the  beginning  of  the 
project  what  characteristics  are  critical  to  the  tasks  to  be  accomplished  (whether  the  pro¬ 
ject  involves  design  of  a  new  system,  redesign,  code  maintenance,  etc.).  Once  this  is 
determined,  the  various  tools  can  be  compared  against  these  critical  success  factors  until 
the  tool  meeting  most,  if  not  all,  factors  is  selected. 

We  selected  the  CASE  tool  suite  produced  by  Cadre  Technologies  called  Teamwork  to  be 
utilized  in  the  redesign  portion  of  the  project  (specific  tools  included  -  structured  analysis, 
structured  design,  Ada  structure  graphs,  and  Ada  Code  Generator  -  as  well  as  the  re¬ 
quired  Teamwork  environment  module).  The  primary  reasons  these  tools  were  selected 
was  because  they  supported  both  object-oriented  and  functional  decomposition  design 
methods,  generation  of  template  Ada  code,  and  support  for  2167  documentation.  This 
was  also  a  fairly  mature  product,  well  supported,  and  one  of  the  most  popular  CASE  tools 
on  the  market. 

The  Teamwork  CASE  tools  included  modules  for  system  analysis,  information  modeling, 
real-time  system  analysis,  system  design,  and  a  utility  called  Teamwork/access  which 
controls  access  to  other  software  development  packages,  project  management  systems, 
and  document  production  systems.  All  Teamwork  components  work,  look,  and  feel  simi¬ 
lar.  The  user  interface  consisted  of  a  mouse-driven  windowing  environment  containing 
pop-up  and  pull-down  menus.  Multiple  windows  could  be  edited  simultaneously. 

All  Teamwork  products  access  a  project  database  that  collects  project  models  and  their 
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model  objects  (Structure  Charts,  Data  Flow  Diagrams,  module  specifications,  etc.).  This 
database  creates  a  development  environment  to  completely  support  the  analysis  and  de¬ 
sign  phase  of  software  life  cycle  development  by  furnishing  a  common  interface  to  model 
objects. 

Consideration  was  given  to  purchasing  re-engineering/restructuring  tools  (e  g.  Bachman 
toolset  which  is  also  good  for  data  modeling),  however,  the  decision  was  made  not  to  due 
to  the  expense  of  such  tools.  If  the  system  being  re-designed  was  large  and  complex, 
such  tools  could  play  a  critical  role. 


3.3.  IMCSRS  Redesign 


One  of  the  issues  to  be  explored  during  this  project  was  to  examine  which  design  method 
-  object-oriented  or  functional  decomposition  -  is  the  more  appropriate  for  STAMIS-like 
systems.  Object-oriented  design  is  a  fairly  new  and  unproven  method  to  design  systems, 
yet  guidance  is  to  utilize  this  method  for  (re)design  activities.  Functional  Decomposition 
is  the  more  traditional  and  accepted  design  method.  To  explore  this  issue,  project  mem¬ 
bers  were  divided  into  two  teams  -  one  re-designed  IMCSRS  using  the  object-oriented 
approach  and  the  other  using  Functional  Decomposition.  A  comparison  of  the  two  de¬ 
signs  is  provided  later  in  the  paper,  however,  the  general  conclusion  is  that  object-ori¬ 
ented,  while  being  a  more  difficult  method  initially,  produces  a  design  that  is  better 
suited  for  re-use,  maintainability,  and  simplification  of  complex  systems. 


3.3.1.  Reverse  Engineering 

In  the  absence  of  an  automated  tool  to  perform  an  analysis  of  the  source  code,  a  task 
order  was  undertaken  to  investigate/develop  a  method  to  reverse  engineer  the  IMCSRS 
systems.  The  findings  of  this  task  outlined  a  method  for  determining  the  original  func¬ 
tional  requirements  of  the  system  from  existing  code.  This  involved  a  bottom  up  analysis 
and  transformation  of  source  code  coupled  with  a  top  down  construction  of  the  problem 
description. 

3. 3. 1.1.  Overview  of  Reverse  Engineering  Methodology 

A  method  to  reverse  engineer  a  system  is  through  the  process  of  "synchronized  refine¬ 
ment”.  Synchronized  refinement  relates  the  execution  of  the  program  with  the  program’s 
functional  requirements.  This  is  done  by  simultaneously  performing  a  bottom-up  analy¬ 
sis  of  the  source  code  with  a  top-down  synthesis  of  the  application  model.  Synchronized 
refinement  should  be  applied  only  in  situations  where  a  detailed,  line-by-line  analysis  of 
the  source  code  is  required.  The  analysis  is  controlled  by  the  determination  of  design 
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decisions. 


Design  decisions  are  data  structures  and  coding  practices  intended  to  accomplish  struc¬ 
tural  goals  of  the  designer.  When  a  program  is  written,  the  original  designer  makes  a 
series  of  decisions  to  form  a  solution  to  a  problem  by  decomposing  it  into  pieces  and  then 
indicating  how  the  pieces  work  together  to  solve  the  problem.  The  type  of  design  deci¬ 
sions  normally  done  during  the  reverse  engineering  process  are  the  following: 

1.  Composition/decomposition  -  Programs  are  built  up  from  separate  modules.  This  is 
usually  implemented  in  the  code  using  separate  procedures  to  divide  the  program  into 
parts. 

2.  Encapsulation/interleaving  -  Sub-components  interact  with  each  other.  If  the  interac¬ 
tions  are  limited  and  occur  through  explicit  interfaces,  the  component  is  said  to  be  encap¬ 
sulated.  If  two  or  more  components  use  the  same  section  of  code  or  the  same  data 
structure,  they  are  considered  to  be  interleaved. 

3.  Generalization/specialization  -  A  program  data  structure  performs  a  similar  function 
or  ir.  coded  similar  to  another  component. 

4.  Data/Procedure  -  The  designation  of  program  variables  and  procedures  is  a  design 
decision  that  may  give  information  as  to  program  function,  if  the  designer  chooses  appro¬ 
priate  names  for  the  application. 

3.3. 1.2.  Project-specific  Approach 

One  of  the  outputs  this  task  was  a  high  level  description  of  the  Installation  Material  Con¬ 
dition  Status  Reporting  System  (IMCSRS)  -  an  operational  STAMIS  that  we  had  selected 
for  redesign.  The  current  IMCSRS  system  is  composed  of  approximately  10,000  lines  of 
COBOL  code  and  is  batch  oriented.  This  high  level  specification  provided  the  starting 
point  (an  overall  view  of  the  system’s  functions)  for  a  more  detailed  system  description 
that  could  be  used  as  the  input  to  the  redesign  phase.  The  following  steps  outline  the 
additional  re-engineering  steps  taken  to  produce  a  detailed  requirements  definition: 

(a)  Before  a  system  can  be  re-designed,  the  current  system  characteristics/functions  must 
be  well  documented  and  understood.  Because  a  functional  description  for  the  IMCSRS 
system  had  never  been  documented,  this  was  the  first  task  to  be  completed.  Input  into  the 
creation  of  the  functional  description  included  system  user  manuals,  programmers  guide, 
maintenance  guide,  and  relevant  regulations  governing  the  system,  interviews  with  the 
system  maintainer(s),  and  source  code.  A  key  to  understanding  a  system’s  functioning  is 
to  concentrate  on  inputs  and  outputs.  Most  ST AMISs  are  primarily  concerned  with  data 
collection  and  the  production  of  various  reports.  If  intermediate  or  output  information  is 


-  8  - 


derived  from  input  data,  the  relevant  code  must  be  located  and  examined  in  detail. 

Once  the  current  system  functioning  was  documented,  the  next  step  involved  the  produc¬ 
tion  of  a  new  functional  description  (requirements  documentation)  to  include  new  func¬ 
tionality  to  be  added  to  the  re-designed  system  (e.g.  interactive  processing,  interactive 
data  validation,  .  .  .  ).  Once  this  has  been  accomplished,  the  functional  description  must 
be  validated  with  the  appropriate  personnel  to  include  the  system  maintainer,  end-users, 
and  the  Functional  Proponent.  This  functional  decomposition  walk-through  is  to  ensure 
that  no  requirements  have  been  missed. 

During  the  re-engineering  process  it  is  important  to  not  go  into  great  detail  with  the 
existing  code  -  if  you  do  you  will  simply  be  re-implementing.  The  key  is  to  discover  the 
basic  functions  (as  the  system  currently  runs),  then  add  new  desired  features  (interac¬ 
tivity,  etc.). 

The  methodology  used  relied  on  a  variety  of  representation  techniques  .  The  were  4  main 
steps  involved  in  reverse  engineering  IMCSRS: 

1.  Construct  a  textual  description  of  the  application.  Concurrently  devise  and  revise  a 
system’s  requirements  summary. 

2.  Construct  nested  Data  Flow  diagrams  describing  the  relationships  among  the  system’s 
cycle,  programs  and  major  files. 

3.  Construct  Jackson  Diagrams  describing  the  structure  of  the  files  used  in  the  system. 

4.  Analyze  the  algorithmic  structure  of  the  system  using  the  process  of  Synchronized 
Refinement. 

Textual  Description 

The  textual  description  was  written  to  obtain  an  initial  understanding  of  the  application 
domain  that  the  system  models  . 

a.  The  description  was  derived  from  information  external  to  the  actual  system  source 
code.  This  was  based  on  system  documentation,  (user  guides,  operating  manuals)  fur¬ 
nished  with  IMCSRS. 

b.  At  the  textual  description  level,  references  were  not  made  to  the  programs’s  internal 
structure  or  to  the  programming  language  used  in  order  to  maintain  a  high-level  of  ab¬ 
straction. 
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c.  The  process  of  deriving  the  description  was  repeated  at  the  subprogram  and  program 
levels.  Each  process  was  described  in  terms  of  the  requirements  placed  on  it  by  the 
system. 

d.  A  summary  was  produced  that  consolidated  the  overall  functional  system  requirements 
in  a  list  format  from  the  textual  description. 

Data  Flow  Diagram 

The  next  step  in  the  methodology  is  the  construction  of  Data  Flow  Diagrams  (DFD) 
DFDs  characterize  the  major  functional  activities  and  files  contained  in  the  system.  Be¬ 
ginning  with  a  Context  Diagram  that  described  the  overall  system  behavior,  multiple  lay¬ 
ers  of  DFDs  were  constructed  in  a  nested,  hierarchical  structure. 

Jackson  Diagrams 

After  the  Data  Flow  Diagrams  were  constructed,  the  input/output  structure  of  each  pro¬ 
gram  was  developed  to  give  a  more  detailed  description  of  the  files.  The  technique  used 
to  represent  this  information  is  called  a  Jackson  Diagram. 

Note:  The  CASE  tools  used  in  this  effort  (IDE’s  SOFTWARE  THROUGH  PICTURES)  pro¬ 
vided  an  editor  to  construct  Jackson  Diagrams.  The  editor  was  integrated  with  a  Data 
Dictionary  and  could  perform  consistency  checks  on  the  constructed  diagrams. 

Code  Analysis 

It  was  necessary  to  acquire  a  better  understanding  of  the  functions  of  IMCSRS.  The  docu¬ 
mentation  was  at  times  ambiguous  and  the  program  had  been  modified  using  non-struc- 
tured  programming  practices  making  the  code  hard  to  follow.  The  code  had  to  be  inter¬ 
preted  by  performing  a  line-by-line  analysis.  This  technique  of  synchronized  refinement 
resulted  in  an  annotated  structural  description  of  how  the  system  functions. 

Synchronized  Refinement  was  accomplished  to  some  extent  by  the  use  of  the  multiple- 
window  environment  provided  on  the  SUN  workstation.  We  designated  two  windows  for 
the  code  analysis  and  application  synthesis  activities.  Steps  were  eliminated  by  using  a 
source  code  control  system  such  as  SCCS  available  under  UNIX. 


3.3.2.  Object-Oriented  Design  (OOD) 
3.3.2. 1  Overview  of  OOD  Methodology 
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Object-oriented  design  is  a  new  approach  to  system  modeling  that  evolved  as  a  natural 
consequence  to  object-oriented  programming.  There  is  currently  no  universally  agreed 
upon  definition  of  what  constitutes  the  object-oriented  design  approach.  It  has  been 
described  as  a  cognitive  process  for  capturing,  organizing,  and  communicating  the  essen¬ 
tial  knowledge  of  the  system’s  ’’problem  space’’  and  for  the  model  formed  gives  guidance 
on  using  specific  techniques  to  map  this  ’’problem  space”  to  a  ’’solution  space”.  The 
method  focuses  on  the  concept  of  abstraction  -  illuminating  important  system  attributes/ 
entities/objects  and  suppressing  other  low  level  physical/functional  implementation  con¬ 
siderations.  Terms  such  as  information  hiding,  ’’black  box”  design,  or  encapsulation  have 
also  been  used  to  describe  this  method  because  information  concerning  detailed  design  or 
implementation  features  need  not  be  known  by  multiple  developers  implementing  a  sys¬ 
tem  designed  in  this  manner  -  only  the  interface  specification  need  be  known.  With  this 
method  systems  are  decomposed  based  on  the  principle  of  hiding  the  design  and  imple¬ 
mentation  decisions  about  the  abstractions.  Only  the  interface  need  be  known  to  instan¬ 
tiate  an  object  or  process  within  an  object. 

In  the  object-oriented  environment,  data  are  primary,  procedures  are  secondary,  func¬ 
tions  are  associated  with  related  data,  and  a  bottom-up  approach  is  used  for  develop¬ 
ment.  The  major  impedance  to  acceptance  of  this  method  is  that  it  involves  an  unfamiliar 
way  of  thinking  to  most  system  designers  (data  versus  functional  perspective). 

An  object  is  defined  as  an  entity  (file,  device,  organizational  unit,  events,  physical  loca¬ 
tions,  etc.)  that  is  itself  defined  by  a  set  of  common  attributes  and  services  or  operations 
associated  with  it  (sort,  retrieve  value,  read,  write,  etc.). 

Perhaps  the  strongest  features  of  this  design  approach  include  increased  reusability, 
maintainability,  understandability,  and  partitioning  of  the  problem  so  that  several  pro¬ 
grammers  can  implement  the  system  concurrently  and  with  little  communication  if  the 
interfaces  have  been  well  defined. 

The  object-oriented  design  process  involves  the  following  phases: 

1.  identify  the  objects  and  their  attributes 

2.  identify  the  operations  suffered  by  and  required  of  each  object 

3.  establish  the  visibility  of  each  object  in  relation  to  other  objects 

4.  establish  the  interface  for  each  object 

5.  implement  each  object 

The  Object-oriented  Design  (OOD)  methodology  was  studied  in  ’’Software  Engineering 
with  Ada",  Grady  Booch,  Second  Edition  (1986).  This  book  is  an  excellent  guide  to 
learning  OOD  and  applying  it  to  the  Ada  programming  language.  Note  that  the  objective 
of  the  book  is  not  to  give  the  reader  detailed  instruction  on  the  Ada  language,  rather  a 


n  - 


study  of  OOD  and  how  it  applies  to  Ada.  It  uses  good  examples,  working  from  simple  to 
more  complex.  Each  example  presenting  a  more  detailed  study  of  OOD  and  Ada.  This 
book  can  be  used  as  a  self-study  guide  for  even  the  beginning  programmer.  It  was  used 
as  the  "bible”  for  design  of  IMCSRS.  The  only  shortcoming  of  the  book  is  in  its  editing. 
Many  typing  errors  can  be  found  in  the  example  Ada  code  causing  some  confusion  and 
frustration  to  the  reader. 

The  object-oriented  development  method  allows  a  designer  to  capture  the  ’’real  world” 
problem  domain  in  the  software.  The  software  and  data  structures  can  actually  ’’look” 
like  the  problem  domain  being  implemented.  The  steps  currently  being  used  for  object- 
oriented  design  follows: 

1.  Identify  the  objects  and  their  attributes. 

2.  Identify  the  operations  that  affect  each  object  and  the 
operations  that  each  object  must  initiate. 

3.  Establish  visibility  of  each  object  in  relation  to  other 

objects. 

4.  Establish  the  interfaces  of  each  object. 

5.  Implement  each  object. 

Identifying  the  objects  is  the  most  difficult  step  in  the  design  methodology.  A  program¬ 
mer  can  more  easily  associate  data  with  an  article,  device,  item,  any  world  "thing.” 
These  objects  can  be  a  unit,  device,  telephone,  gas,  data  base  or  any  abstract  object. 
Abstract  objects,  such  as  speed  and  time,  do  not  have  form.  Each  object  has  associated 
with  it  attributes  that  define  the  object.  For  the  object  HUMAN,  some  of  the  attributes 
are  sex,  height,  weight  and  age.  More  appropriately,  the  attributes  for  EMPLOYEE  could 
be  social  security  number,  employee  number  and  salary.  Buhr  represents  an  object  by  a 
rectangle.  The  attributes  are  not  graphically  represented  but  are  implemented  as  fields  in 
the  defining  data  structure. 
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EMPLOYEE 


Each  object  has  operations  that  act  on  it.  Some  of  the  operations  are  active,  others 
passive.  The  active  operations  alter  the  object’s  state  and  the  value  of  it's  attributes.  The 
passive  operations  do  not  alter  the  object  but  usually  return  the  values  of  the  object’s 
attributes.  The  operations  are  established  either  as  visible  operations  which  are  accessi¬ 
ble  by  other  objects  or  local  operations  that  can  only  be  used  by  the  object  itself.  Each 
operation  is  displayed  as  a  smaller  rectangle  inside  the  object.  Buhr  diagrams  identify 
visible  operations  by  "binding”  them  to  the  object.  The  binding  is  represented  by  attach¬ 
ing  the  operation  to  the  side  of  the  object. 
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Local  operations  are  illustrated  by  separating  the  operation  from  the  side  of  the  object. 


EMPLOYEE 


SORT 


Once  all  of  the  objects,  their  attributes  and  operations  have  been  defined,  the  visibility 
between  objects  must  be  established.  The  visibility  will  determine  if  one  object  "sees”  or 
has  access  to  the  operations  or  attributes  of  another  object.  It  is  imperative  for  good 
software  engineering  to  limit  the  visibility  as  much  as  possible.  Buhr  diagrams  illustrate 
visibility  by  a  directional  arrow. 
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In  this  Buhr  diagram.  Objects  B  &  C  are  visible  to  Object  A.  Object  D  is  visible  to  Object 
C.  Object  A  is  not  visible  to  any  other  object. 

The  next  design  step  is  to  establish  the  interfaces  between  objects.  The  parameters  passed 
between  the  initiating  object  and  the  receiving  object  must  be  established.  The  parame¬ 
ters  are  defined  as  in  ,  out  ,  and  in-out.  The  in  parameters  are  sent  to  the  operation. 
The  out  parameters  are  received  from  the  operation  and  the  in-out  parameters  are  sent  in 
to  the  operation,  modified  and  sent  back  out  of  the  operation.  The  Buhr  diagram  illus¬ 
trates  these  interfaces  with  a  directional  arrow,  the  parameter  mode,  formal  parameter 
and  parameter  type. 

In  the  following  diagram,  the  in-out  parameter  ALL_EMPLOYEES  of  type  EMPLOYEES 
is  being  passed  to  the  SORT  object  for  manipulation  and  return  to  the  originating  object 
after  modification.  The  in  parameter  THE_EMPLOYEE_FTLE  of  type  EMPLOYEE  FILE 
is  being  passed  to  the  LOAD  object  in  order  to  initiate  a  process,  in  this  case,  the  loading 
of  the  file  to  be  manipulated.  The  contents  of  the  parameter  are  not  modified  and  are  not 
returned  to  the  originating  object.  The  parameter  attributes  and  types  are  stored  in  a  data 
dictionary  and  must  be  consistent  when  interfacing  objects  (i.e.  the  type  of  parameter 
must  agree  between  objects). 
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THE_EMPLOYEE_FILE  :  EMPLOYEEFILE 


The  final  step  in  the  design  is  to  implement  each  object.  The  data  structures  representing 
the  object  will  primarily  be  based  on  the  object  attributes.  The  bodies  of  the  operations 
must  then  be  developed. 

3.3.2.2  Project-specific  Approach 

The  first  step  in  the  object-oriented  design  was  to  develop  a  functional  description  for  the 
system.  The  requirements  had  to  be  defined  as  specifically  as  possible.  The  information 
was  taken  from  the  current  COBOL  system  maintenance  manual  and  available  user 
guides.  One  of  the  most  useful  tools  which  helped  with  understanding  the  system,  was 
the  creation  of  a  ’’System/User”  chart.  The  chart  showed  the  interface  between  the  soft¬ 
ware  and  the  user.  The  information  on  the  chart  included  but  was  not  restricted  to  the 
following 

1.  Software  locations. 

2.  Hardware  types,  (mainframe,  PC,  etc). 

3.  Communications  (Autodin,  Modems,  etc). 

4.  Input  sources. 

5.  Report  Destinations. 

6.  Overall  responsibilities  for  the  system. 

7.  Location  of  input/output  processing. 
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The  COBOL  version  of  IMCSRS  was  used  at  the  installation  level,  division  level  and 
regimental  level.  The  system  was  processed  on  an  Amdahl  mainframe  at  the  installation 
level  and  on  a  Honeywell  mainframe  at  the  division/regiment  level.  Trunks  of  the  ASIMS 
(Army  Standard  Information  Management  Systems)  network  as  and  the  Autodin  network 
at  the  telecommunications  centers  (TCC)  were  used  to  transfer  data  to  Forces  Command 
(FORSCOM),  Training  and  Doctrinal  Command  (TRADOC)  and  Materiel  Readiness  Sup¬ 
port  Activity  (MRSA).  Inputs  came  from  reportable  units  in  the  form  of  hard  copy  DA 
Form  2406  and  a  pre-processed  file  of  2406  information  from  the  sub-units.  Addition¬ 
ally,  a  reportable  equipment  file  was  sent  from  FORSCOM  via  the  ASIMS  network  to  the 
DOL  (Directorate  of  Logistics). 
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Reports  went  to  the  DOL  who  had  overall  responsibility  for  running  the  system.  Because 
the  system  was  operated  on  the  Regional  Data  Center  (RDC)  the  Director  of  Information 
Management  (DOIM)  at  each  installation  actually  input  the  data  and  received  the  output 
reports  which  were  then  delivered  to  the  DOL. 

After  the  functional  description  was  validated  for  correctness,  the  system  was  designed 
using  object-oriented  procedures.  One  of  the  basic  goals  of  object-oriented  design  is  to 
mirror  the  real  world.  The  System/User  chart  established  a  base-line  to  better  understand 
the  system  and  serve  as  a  blueprint  for  developing  the  object-oriented  design.  Buhr 
diagrams  were  used  to  illustrate  the  design  by  CADRE’S  ’’Teamwork”  CASE  Tool.  Grady 
Booch’s  methodology  was  followed  for  the  object-oriented  design.  The  following  steps 
were  used  to  develop  the  object-oriented  design  of  the  system: 

1.  Developed  a  ’’System/User”  chart. 

2.  Identified  the  objects. 

3.  Identified  the  attributes  of  each  object. 

4.  Identified  the  operations  that  affect  each  object  and  the 

operations  that  each  object  must  initiate. 

5.  Established  visibility  of  each  object  in  relation  to 

other  objects. 

6.  Established  the  interfaces  of  each  object. 

7.  Implemented  each  object. 

These  steps  were  repeated  many  times  during  design  refinement. 

The  new  System/User  chart  was  a  modification  of  the  mainframe  version.  The  inputs  and 
outputs  remained  the  same  but  the  processing  requirements  were  relocated.  The  system 
was  moved  from  a  mainframe  computer  to  a  personal  computer  at  the  DOL.  All  inputs 
and  outputs  would  be  processed  at  the  DOL.  The  DOIM  would  no  longer  be  required  to 
key  the  data  to  tape  and  run  the  batch  system.  Their  only  function  would  be  to  convert 
the  desktop  system  output  on  disk  to  a  format  acceptable  for  transmission  over  the 
Autodin  network. 

Once  the  new  System/User  chart  was  developed,  it  was  easy  to  identify  the  system  ob¬ 
jects.  These  high  level  "real  world”  objects  were  divided  into  four  classes: 

1.  Reportable  Units  -  the  units  that  were  required  to  report  on 
the  DA  Form  2406. 

2.  Reportable  Equipment  -  the  equipment  identified  as 
reportable  items. 

3.  Unit  2406s  -  the  hard  copy  DA  Form  2406. 
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4.  Reports  -  hard  copy  and  files  generated  by  the  system. 


REPORTABLE  UNITS 

REPORTABLE 

REPORTS 

EQUIPMENT 

UNIT  2406s 

Other  objects  were  defined  during  design  refinement.  These  objects,  often  referred  to  as 
’’abstract”  objects,  were  used  to  supplement  the  "real-world”  objects.  Five  abstract  ob¬ 
jects  were  defined: 

1.  Synchronizer  -  to  manage  the  data  bases. 

2.  Retrievers  (3)  -  Retrieve  Unit,  Retrieve  Equipment  and  Retrieve 
2406  to  give  easy  access  to  the  data  by  the  Reports  object. 

3.  Command  I/O  -  to  control  all  high  level  menu  display  and 

selection  operations. 
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REPORTABLE  UNITS 

RETRV  UNIT 

COMMAND  I/O 

REPORTABLE 

EQUIPMENT 

SYNCHRONIZER 

RETRV  EQUIPMENT 

REPORTS 

UNIT  2406s 

RETRV  2406 

Attributes  were  selected  to  define  each  object  using  the  header  information  on  the  DA 
Form  2406.  Other  information  needed  to  define  the  unit  was  subsequently  added.  Re¬ 
portable  Units  were  defined  by  the  following: 

1.  Unit  Identification  Code  (UIC) 

2.  Utilization  Code 

3.  To  Installation 

4.  From  Unit 

5.  TOE_Number 

6.  Station/Division  Code 

Reportable  Equipment  attributes  were  limited  to  items  defining  a  general  piece  of  equip¬ 
ment.  Only  items  of  information  that  were  common  to  all  ECC/LJN  and  models  of 
Army-wide  equipment  were  included.  Reportable  Equipment  was  defined  by  the  follow¬ 
ing: 

1.  ECC/UN 

2.  Noun 

3.  Model 

4.  DA  Organizational  Readiness  Rate  Average 

The  Unit  2406  was  defined  by  the  fields  on  the  actual  DA  Form  2406.  The  information 
was  unique  to  the  equipment  posture  of  a  specific  unit.  All  general  information  was 
captured  in  the  Reportable  Units  and  Reportable  Equipment  objects.  DA  Form  2406  is 
divided  into  two  parts,  the  header  and  equipment  status  (line  items).  The  Unit  2406 
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object  was  divided  in  the  same  two  parts  to  parallel  the  form.  The  outermost  package 
defined  the  overall  DA  Form  2406  and  included  the  following: 

1.  Period  of  Report  (From) 

2.  Period  of  Report  (To) 

3.  Date  Prepared 

4.  Line  Items 

An  object  Line  Item  was  derived  as  a  smaller  object  of  the  object  Unit  2406.  It  was 
defined  by  the  following  attributes: 

1.  Sequence  Number 

2.  ECC/UN 

3.  Model 

4.  Effect  on  System  Code 

5.  Equipment  Utilization  Code 

4.  Authorized  Quantity 

5.  On  Hand  Quantity 

6.  Possible  Days 

7.  Available  Days 

8.  Non-Available  Days  due  to  Organizational  Supply 

9.  Non-Available  Days  due  to  Organizational  Maintenance 

10.  Non-Available  Days  due  to  Support  Supply 

1 1 .  Non-Available  Days  due  to  Support  Maintenance 

During  implementation  the  attributes  became  fields  of  the  records  representing  these  vari¬ 
ous  objects. 

Once  each  object  was  clearly  defined,  the  operations  that  affected  the  object  had  to  be 
identified.  The  basic  operations  were  the  same  for  each  object.  The  Reportable  Units, 
Reportable  Equipment  and  Unit  2406s  had  to  be  Added  to  a  list,  Deleted  from  a  list  and 
Modified.  The  operations  getting  the  information  from  the  user  for  each  attribute  had  to 
be  defined  (ie:  GetJECC,  Get_NOUN  etc).  They  also  had  to  be  Sorted  and  Searched.  At 
a  very  detailed  level,  the  implementation  had  to  be  considered.  When  each  object  '^as 
represented  by  a  file  more  operations  surfaced:  Open,  Close,  Create,  Save,  Load  and 
Compact. 

Some  of  these  operations  were  determined  to  be  ’’visible”  or  available  to  an  outside 
object;  other  operations  would  be  used  locally  by  the  object  itself.  In  the  Buhr  diagrams 
the  visible  operations  were  ’’bound”  or  touching  the  package  (ADD.  MODIFY),  where  the 
local  operations  were  separate  (SORT,  SEARCH). 
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The  ’’Retrievers”  were  defined  to  have  one  passive  operation  per  object  attribute.  It  was 
defined  as  passive  since  it  had  access  to  the  data  structure  but  could  not  alter  it.  The 
function  would  reach  into  the  data  base  and  retrieve  the  value  of  the  specific  attribute  in 
the  format  defined.  The  data  structure  would  remain  unchanged.  For  example.  Retrieve 
Equipment  was  defined  to  have  the  following  ’’passive”  operations  (functions): 

1.  ECCJLJN  -  returns  the  current  equipment  ECC/LIN. 

2.  Noun  -  returns  the  current  equipment  name. 

3.  Model  -  returns  the  current  equipment  model. 

4.  DA  OR  Average  -  returns  the  current  equipment  DA  operational 
readiness  rate. 

5.  First  Equipment  -  returns  the  position  of  the  first  piece  of 
equipment  in  the  list. 

6.  Last  Equipment  -  returns  the  position  of  the  last  piece  of 
equipment  in  the  list. 

The  Synchronizer  was  designed  to  control  the  data  base  for  the  Reports  object.  It  per¬ 
formed  nine  operations. 

1.  Reset  Units,  Reset  Equipment  &  Reset  2406  Items  -  moves  to 

the  first  element  in  the  list. 

2.  Next  Unit,  Next  Equipment,  Next  2406  Item  -  moves  to  the 

next  element  in  the  list. 

3.  Find  Equipment,  Find  Unit  -  locates  a  particular  element  in 
its  respective  list. 
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Minimizing  the  interfaces  with  other  objects  was  a  primary  concern.  Grouping  the  object 
with  its  operations  met  this  goal;  however,  an  object  on  its  own  serves  no  purpose — 
another  object  must  use  the  operations  associated  with  it.  For  example,  the  Reports 
objects  did  not  need  to  ’’see”  the  database.  If  the  database  was  to  be  changed,  the  output 
reports  would  not  have  to  be  rewritten.  That  was  the  primary  reason  for  the  passive 
’’retriever”  packages.  The  ’’retrievers”  would  serve  as  an  interface  between  the  database 
and  the  report  writers.  Unless  an  object  had  a  good  reason  for  altering  or  even  ’’seeing” 
another  object,  it  was  not  given  visibility.  So  the  visibility  sequencing  started  at  the 
database. 


The  main  procedure,  Process  EMCSRS,  was  assigned  visibility  to  all  three  data  bases, 
Reportable  Units,  Reportable  Equipment  and  Unit  2406s.  This  visibility  was  necessary  to 
Add,  Delete  and  Modify  the  specific  objects  within  each  class.  The  main  procedure  also 
was  assigned  visibility  to  Command  I/O  and  Reports  allowing  control  of  the  selected 
commands/menus  as  well  as  report  generation. 
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The  Synchronizer  was  also  given  visibility  to  all  the  three  data  bases  to  ensure  necessary 
data  was  pulled  into  memory  from  the  files  at  the  appropriate  time.  The  Reportable  Unit 
would  be  brought  into  memory  along  with  its  associated  2406.  The  first  line  item  would 
be  located  on  the  2406  and  the  Reportable  Equipment  information  would  be  brought  into 
memory.  All  necessary  information  would  be  in  memory  for  use  by  the  Reports  object  to 
write  reports. 


The  "retrievers”  were  given  visibility  to  their  associated  database  only.  Each  attribute  for 
that  particular  object  would  be  accessible  through  the  three  retrievers.  For  example. 
Retrieve  Unit  had  visibility  only  to  Reportable  Units. 


RETRY  2406 


LINE  ITEM 


The  RETRV  2406  was  designed  to  look  like  DA  Form  2406.  The  header  information  was 
contained  in  the  basic  package;  the  specific  line  item  information  was  contained  in  the 
object  Line  Item. 


Reports  was  given  visibility  to  the  ’’retrievers”  and  the  Synchronizer.  It  had  to  have 
access  to  the  data  via  the  ’’retrievers”  and  control  of  selecting  data  from  the  three  data 
bases  via  the  synchronizer.  The  Reports  object  could  then  manipulate  and  use  informa¬ 
tion  from  the  data  base  without  knowing  how  it  was  physically  structured.  By  ’’hiding” 
the  physical  structure  of  the  data  base  from  the  report  writers,  the  data  base  could  be 
removed  and  replaced  in  the  future  with  a  faster  commercial  data  base  management 
system  without  the  reports  being  rewritten. 

The  visibilities  were  established  to  give  specific  objects  access  to  operations  and  data  of 
another  object.  The  interfaces  between  the  operations  were  established.  The  data  that 
was  sent  and  received  between  operations  was  identified  and  used  in  a  subprogram  for¬ 
mal  parameter  to  establish  the  interface.  For  example,  the  SORT  operation  of  Reportable 
Units  would  accept  a  table  of  type  Unit  Location  Table,  sort  it  in  ascending  order  and 
return  it.  The  couple  (bi-directional  arrow)  displays  an  in-out  parameter.  If  the  arrow 
pointed  toward  the  operation  it  would  be  an  in  parameter  only,  and  inversely,  if  it  pointed 
away  from  the  operation,  the  parameter  would  be  an  out  parameter  only. 


The  high  level  components  of  the  system  were  completed  with  the  establishment  of  the 
object  interfaces.  The  system  had  been  separated  into  logical  objects  that  reflected  the 
real  world.  The  operations  required  to  operate  on  each  of  the  objects  had  been  identified 
and  the  visibility  between  objects  and  interfaces  to  allow  the  operations  to  be  accessed 
had  been  established.  The  design  was  ready  for  implementation.  To  implement  the 
design,  only  the  data  structures  used  to  represent  the  objects  and  the  bodies  of  each 
operation  need  to  be  written. 
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3.3.2.3.  Results  (Ada  Structure  Graphs,  Ada  Code) 

The  redesign  resulted  in  three  significant  products.  An  up  to  date  functional  description 
was  developed  and  used  as  a  contract  between  the  Proponent  Agency  and  the  designers. 
It  specified  exactly  what  the  proponent  wanted  the  system  to  do.  The  requirements  defini¬ 
tion  is  so  critical  during  design  that  the  functional  description  was  mandatory. 

Ada  Structure  Graphs  (ASG)  were  generated  by  the  CADRE  ’’Teamwork”  CASE  tool. 
They  implement  ”Buhr  Diagrams”  giving  a  high  level  view  of  the  system.  They  are  easy 
to  modify  for  future  software  changes  and  should  be  an  integral  part  of  the  programmers 
maintenance  manual.  The  system  is  easily  learned  from  these  graphs.  These  diagrams 
can  easily  be  translated  into  code  specifications.  The  ’’invocations”  or  visibility  lines 
generate  the  Ada  ’’with”  statements.  The  packages  and  subprograms  are  interpreted  as 
the  associated  package,  procedure,  function  and  task  subprograms.  The  invocations  with 
coupling  will  show  subprogram  specifications  with  parameters.  All  design  specifications 
to  include  the  most  detailed  interfaces  can  be  derived  from  these  graphs. 

The  ’’Teamwork”  CASE  tool  included  Code  Generator  (CG)  that  interpreted  the  Ada 
Structure  Graphs  (ASG).  The  system  read  the  Buhr  diagrams  and  generated  the  system 
specifications.  These  system  specifications  were  in  usable  Ada  specification  format. 
Body  ’’stubs”  were  also  generated  for  each  package  and  subprogram.  The  system  allowed 
notes  which  were  inserted  into  the  code  as  exceptions,  data  structures  and  program  logic 
to  be  attached  to  each  object  .  This  code  was  then  processed  with  a  simple  compiler  that 
checked  the  design  logic  for  completeness.  It  generated  errors  specifying  the  location  of 
the  incorrect  design.  After  a  clean  compile,  the  Ada  specifications  and  bodies  were 
written  to  separate  files  for  use  during  implementation. 

3.3.3.  Functional  Decomposition  (Structured  Analysis  and  Design) 

3.3.3. 1  Overview  of  Structured  Design  Methodology 

The  method  for  redesign  of  IMCSRS  from  the  functional  decomposition  side  of  the  pro¬ 
ject  consisted  of  a  structured  development  methodology.  In  this  approach,  the  system  is 
analyzed  from  a  functional  perspective.  The  functions  and  procedural  nature  of  the  sys¬ 
tem  were  of  primary  interest;  the  data  is  considered  during  the  later  stages  of  develop¬ 
ment.  The  structured  development  is  made  up  of  two  distinct  phases:  Structured  Analy¬ 
sis  and  Structured  Systems  Design  ("Top-down  design”).  Structured  Analysis  can  be 
described  as  the  activity  of  deriving  a  structural  model  and  the  accompanying  structured 
specifications  to  give  a  clear  “definition  of  the  problem”.  Structured  Design  can  be 
defined  as  the  development  of  a  computer  system  solution  to  a  data  processing  problem, 
creating  a  new  system  containing  the  same  components  and  process  relationships  outlined 
during  the  analysis  of  the  system. 
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The  particular  structured  development  techniques  used  during  the  project  were  those  out¬ 
lined  by  DeMarco  and  Yourdon.  There  are  slightly  different  approaches  to  structured 
analysis,  but  the  DeMarco  method  contained  the  basic  elements  required.  Also,  the  par¬ 
ticular  CASE  tools  chosen  to  implement  the  design  and  analysis  of  the  system  follow  the 
concepts  of  DeMarco  and  Yourdon  in  their  functionality. 

The  structured  analysis  of  a  system  precedes  its  design;  structured  specifications  act  as 
direct  input  for  the  design  phase.  By  developing  a  structured  specification  that  is  graphi¬ 
cal  using  the  CASE  toolset,  we  obtain  a  model  of  the  system  that  is  very  concise  and  easy 
to  interpret. 

The  main  building  block  of  the  Structured  Analysis  of  a  System  is  the  Data  Flow  Diagram 
(DFD).  A  DFD  is  a  graphical  representation  of  a  system  that  depicts  the  active  processes 
and  their  interrelationships.  DFDs  consist  of  4  basic  elements:  Data  Flows  (directional 
arrows)  ,  Processes  (circles)  ,  Data  Stores  (  2  parallel  lines),  and  Sources/Sinks  (rectan¬ 
gles). 

Data  Flows  represent  the  movement  of  data.  This  is  the  symbol  chosen  to  show  the 
interface  between  components  on  a  DFD.  Data  Flows  are  basically  the  media  through 
which  data  are  transmitted.  They  are  labeled  with  names  that  described  the  composition 
of  the  data. 

A  process  bubble  is  placed  on  a  DFD  when  some  transformation  of  data  occurs.  Data 
can  be  manipulated  within  a  process  either  of  2  ways:  (1)  the  structure  of  the  data  can 
change,  producing  as  output  a  reformatted  version  of  the  original  data  (2)  the  information 
in  the  data  can  be  transformed,  generating  new  data.  One  of  the  most  difficult  tasks 
during  the  structured  analysis  phase  is  reducing  system  activities  to  processes  that  trans¬ 
form  data.  Each  process  should  receive  a  descriptive  name  that  gives  a  clear  picture  of 
the  type  of  transformation  occurring  within  the  function. 

A  data  store  is  where  some  temporary  storage  of  data  occurs.  Data  stores  can  represent 
files,  information  on  magnetic  tape,  card  indexes,  entire  databases,  etc. 

The  Source/Sink  symbol  depict  where  the  data  required  by  the  system  originates  and 
where  the  output  of  the  system  ends  up.  A  source/sink  can  be  a  person  or  organization 
external  to  the  system  that  is  the  net  originator  or  recipient  of  data  (a  source  is  a  data 
originator;  a  sink  receives  data).  These  symbols  are  only  present  on  the  context  diagram 
for  a  system.  A  Context  Diagram  is  a  DFD  at  the  highest-level  of  abstraction  for  a 
system;  it  is  usually  shown  as  a  single  process  bubble  containing  the  name  of  the  system 
with  data  flows  to  and  from  sources  and  sinks.  The  context  diagram  should  show'  the 
interface  between  the  outside  world  and  the  system  being  developed. 

The  DFDs  within  the  structured  specification  were  developed  using  top-down  partitioning. 
Top-down  partitioning  allows  the  system  to  be  decomposed  into  a  multidimensional 
arrangement  with  differing  levels  of  detail  so  that  there  is  a  smooth  progression  from  the 
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most  abstract  (top)  to  the  most  detailed  (bottom).  By  assigning  functions  in  the  system  to 
unique  elements  within  a  DFD,  redundancy  is  eliminated.  The  structured  specification 
also  has  to  be  disassociated  with  the  hardware,  vendor,  or  operating  procedures  of  the 
current  environment.  It  needs  to  focus  only  on  how  the  system  functions.  Unlike  conven¬ 
tional  flowcharts,  DFDs  don’t  show  flow  of  control  or  procedure  sequences.  The  system 
specification  should  only  be  concerned  with  the  pieces  of  a  system  and  how  those  pieces 
relate  to  one  another,  not  the  sequence  in  which  they  occur  or  the  number  of  iterations 
involved.  The  main  emphasis  in  a  DFD  is  the  flow  of  data.  The  structured  specification 
is  organized  from  the  viewpoint  of  data,  i.e.  the  processing  that  a  piece  of  data  goes 
through  from  beginning  to  end  of  the  system.  This  gives  a  better  overall  view'  of  the 
system  since  it  is  not  limited  to  how-  a  particular  user  interfaces  with  individual  portions  of 
a  system. 

In  the  structured  design  portion  of  a  system  development,  the  structured  specification 
generated  in  the  analysis  phase  is  utilized  as  a  roadmap  towards  the  new  design.  By  using 
the  structured  specification  as  a  well-defined  statement  of  the  problem,  structured  design 
allows  the  form  of  the  problem  to  guide  the  solution.  The  design  itself  is  not  the  final 
system  but  a  plan  for  implementing  the  new  system.  Structured  design  can  also  help 
outline  a  set  of  criteria  for  evaluating  the  proficiency  of  a  design  solution  as  it  relates  to 
the  original  problem.  Structured  design  derives  a  simplified,  graphical  representation  of  a 
system  by  partitioning  the  functionality  and  organizing  hierarchical  relationships.  Parti¬ 
tioning  systems  modularizes  function;  effectively  isolating  functions  from  updates  and 
changes  in  different  portions  of  a  system. 

The  main  tool  within  structured  design  is  the  structure  chart.  Like  a  DFD,  the  structure 
chart  is  a  multidimensional  arrangement  of  a  system.  A  structure  chart  depicts  the  parti¬ 
tioning  of  a  system  into  modules,  the  organization  and  hierarchy  between  the  modules, 
communication  interfaces  between  the  modules,  and  the  labels  for  the  modules.  The 
basic  elements  within  a  structure  chart  are:  modules,  invocations,  and  couples. 

A  module  is  represented  by  a  rectangular  box.  The  contents  of  a  module  (the  module 
specifications)  are  not  shown  on  the  structure  chart,  but  can  be  considered  as  a  continu¬ 
ous  set  of  program  statements  that  have  in  common  input/output,  function,  mechanics 
and  internal  data.  A  module  could  be  a  subroutine,  a  function,  or  system  call.  System  or 
library  modules  are  called  pre-defined  modules  since  their  development  is  not  part  of  the 
design;  they  perform  a  function  that  can  be  accessed  without  having  to  be  coded.  The 
modules  on  a  structure  chart  serve  the  purpose  of  “black  boxes”  in  that  the  actual  imple¬ 
mentation  of  the  function  are  transparent  to  the  designer.  This  allows  the  programmer 
flexibility  in  coding  a  particular  function  as  long  as  the  input/output  of  the  module  follows 
the  design.  The  function  within  a  module  may  be  further  broken  down  into  sub-functions 
by  invoking  subordinate  modules  at  a  lower  level  of  the  hierarchy.  This  is  in  keeping  with 
the  structured  design  concept  of  “one  function  per  module”  but  allows  subtasks  to  exe¬ 
cute  specific  portions  of  a  function. 
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The  connection  between  modules  (invocation),  depicted  as  an  arrow  from  one  module  to 
another,  shows  module  calls.  Invocations  do  not  show  calling  sequence  for  module  com¬ 
munication  nor  does  it  show  the  number  of  iterations.  It  just  shows  that  a  module  can 
potentially  invoke  a  particular  subordinate  module.  The  details  of  module  access  are 
handled  during  actual  implementation  of  a  function. 

The  communication  between  modules  is  handled  through  coupling.  Module  invocations 
represent  how  modules  are  connected;  couples  show  data  items  moving  from  one  module 
to  the  next.  Graphically,  couples  are  drawn  as  an  arrow  with  a  circular  tail.  The  amount 
of  coupling  between  modules  determines  the  measure  of  independence  between  them. 
The  level  of  coupling  can  also  be  examined  by  the  designer  to  ascertain  the  overall  quality 
of  a  design.  The  higher  the  coupling  (and  therefore,  the  data  dependence)  between  mod¬ 
ules,  the  increase  in  the  probability  of  a  change  in  one  modules,  the  increase  in  the 
probability  of  a  change  in  one  module  affecting  another  module.  Minimizing  the  amount 
of  coupling  minimizes  the  ripple  effect  of  program  changes  and  leads  to  a  system  that  is 
more  robust.  Coupling  within  a  system  can  be  reduced  by  eliminating  unnecessary  rela¬ 
tionships  between  modules. 

Another  method  of  designing  a  more  robust  system  and  ensuring  proper  partitioning  of  a 
structure  chart  is  determining  the  level  of  cohesion  within  a  module.  Cohesion  is  examin¬ 
ing  how  the  activities  within  a  single  module  relate  to  one  another.  Coupling  and  cohe¬ 
sion  are  interdependent  in  that  the  cohesion  of  a  module  directly  affects  the  level  of 
coupling  between  it  and  other  modules.  Constantine  and  Yourdon’s  methodology  of 
structured  design  delineates  7  levels  of  cohesion  possible  between  modules: 

a)  A  functionally  cohesive  module  limits  itself  to  the  performance  of  one  and  only  one 
task.  This  level  of  cohesion  within  a  structure  chart  ensures  the  highest  level  of  maintain¬ 
ability  within  a  system  and  is  the  most  desirable  level. 

b)  Sequential  cohesion  occurs  when  a  module  outputs  information  to  be  used  as  input  in 
another  module  within  a  system.  This  type  of  cohesion  is  maintainable,  but  the  amount 
of  independence  between  modules  is  increased. 

c)  Communicatively  cohesive  modules  contain  elements  that  share  input/output  data 
from  a  common  activity.  Because  of  the  interrelation  between  these  modules  that  share 
access  to  global  data,  there  is  a  tendency  towards  redundant  coupling  or  duplication  of 
function. 

d)  Procedural  cohesion  is  distinguished  by  control  flow  between  activities  that  are  possi¬ 
bly  unrelated  and  execute  different  functions  with  a  module.  This  type  of  cohesion  is 
characterized  by  flags  or  switches  transmitted  as  data  between  modules. 

e)  Temporally  cohesive  modules  are  made  of  elements  that  are  connected  to  each  other 
only  by  a  time  sequence  of  events.  These  elements  in  the  module  do  not  necessarily 
share  functionality.  This  type  of  cohesion  can  also  lead  to  redundant  coupling  since  there 
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may  be  a  tendency  to  reproduce  code  in  other  modules  that  have  the  same  type  of  time 
dependence. 

f)  Logical  cohesion  describes  modules  that  contribute  to  a  similar  category  of  functions 
to  be  executed  external  to  the  module.  In  this  instance,  a  module  is  used  to  perform 
several  functions  depending  upon  how  it  is  invoked.  The  activities  within  the  module  are 
forced  to  share  a  single  interface. 

g)  The  final  type  of  cohesion,  coincidental  cohesion,  is  the  least  desirable  in  that  it 
exhibits  the  worst  level  of  coupling  and  maintainability.  A  coincidentally  cohesive  mod¬ 
ule  performs  activities  that  have  very  little  relation  to  one  another.  They  have  no  well- 
defined  function;  the  calling  module  is  often  tasked  with  sending  a  control  flag  to  the 
receiving  module  to  decide  what  is  to  be  done.  This  requires  the  calling  module  to  be 
aware  of  the  internals  of  the  called  module,  which  violates  the  “black  box"  concept. 

The  DFDs  of  the  structured  analysis  phase  are  converted  into  structure  charts  in  the 
design  phase  through  transform  analysis.  Transform  Analysis  is  a  strategy  for  deriving  a 
first-cut  structure  chart  from  the  analysis  of  a  system.  The  initial  design  is  then  taken 
through  several  iterations  of  refinement  using  the  methods  of  determining  cohesion  and 
coupling.  The  main  difference  between  a  DFD  and  a  structure  chart  is  the  hierarchical 
nature  of  a  structure  chart.  Names  of  a  resulting  structure  chart  do  not  necessarily  relate 
directly  to  names  of  processes  on  the  original  DFD.  The  beginning  of  the  transform 
analysis  process  involves  determining  the  portion  of  a  DFD  that  contains  the  essential 
functions  of  a  system.  This  centra!  transform  will  outline  the  basic  functions  that  must  be 
accomplished  within  a  system  and  lead  directly  to  the  development  of  a  structure  chan. 

3. 3. 3.2  Project-specific  Approach 


The  functional  decomposition  portion  of  the  project  was  accomplished  using  the  Team- 
work/SA  and  TeamworklSD  CASE  tools  available  from  Cadre.  Both  of  these  tools  were 
designed  following  the  structured  analysis  and  structured  design  methodologies  previously 
mentioned. 

Teamwork/SA  is  an  environment  for  systems  analyst  enabling  the  creation  and  verification 
of  functional  systems  specifications.  Teamwork/SA  consists  of  tools  for  the  rapid  creation 
and  editing  of  DFDs,  process  specifications,  and  data  dictionary  entries.  Built-in  Model 
Configuration  Management  tools  organized  models  into  leveled  sets  and  helped  establish 
relationships  between  DFDs  and  their  corresponding  process  specifications.  A  versioning 
facility  provided  an  audit  trail  during  project  development  by  tracking  the  history  of  pro¬ 
ject  updates  for  review.  Teamwork/SA  also  maintains  a  consistency  check  function  with 
detailed  knowledge  of  structured  analysis  that  gauges  system  quality  for  correctness. 

Teamwork/SD  is  an  integrated  set  of  design  aids  for  employing  a  structured  systems  design 
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methodology.  This  tool  for  creating  structure  charts,  module  specifications,  and  other 
graphic  symbols  contained  within  the  design  process  provided  a  rapid  graphical  user  inter¬ 
face  for  planning  a  system.  There  was  also  an  embedded  design  rule  checker  in  Team- 
work/SD  that  would  verify  a  proposed  design’s  overall  validity. 

The  CASE  tools  were  relatively  easy  to  become  familiar  with,  since  there  was  a  standard 
interface  and  access  method  for  the  Cadre  products.  There  was  also  tutorial  information 
for  the  Teamwork/SA  tool  that  familiarizes  the  user  with  the  various  editors  and  object 
creation  tools. 

Learning  the  structured  design/analysis  methodology  was  a  matter  of  reviewing  several 
books,  articles,  and  technical  reports  on  the  subject.  The  choice  of  DeMarco  and  Your- 
don  was  due  to  the  connection  between  their  particular  implementation  of  the  design 
process  and  the  CASE  tools  chosen  to  develop  them.  Since  the  project  was  involved  with 
the  transitioning  from  an  existing  system  to  a  new  design,  parts  of  the  normal  life  cycle 
development  for  a  system  were  either  merged  or  excluded  from  the  actual  steps  in  the 
design.  The  lack  of  functional  users  and  access  to  up-to-date  documentation  on  the 
existing  system  made  it  necessary  to  make  certain  assumptions  about  functionality  within 
the  system.  It  was  not  clear  initially  whether  the  system  was  to  be  designed  as  a  more 
structured  version  of  the  old  system  or  if  a  completely  new  design  with  more  efficient 
functionality  using  better  file  access  methods  was  the  goal.  Originally  we  approached  the 
design  with  the  former  goal  in  mind,  therefore  relying  heavily  on  the  description  of  the 
old  IMCSRS  system.  Once  the  choice  was  made  to  implement  a  new  design  of  the  sys¬ 
tem,  the  old  environment  was  used  only  as  a  foundation. 

3. 3.3.2. 1  Systems  Analysis 

The  initial  problem  in  developing  a  new  design  for  IMCSRS  using  functional  decomposi¬ 
tion  was  to  analyze  the  functional  requirements  of  the  new  system.  The  data  flow  dia¬ 
grams  (DFDs)  developed  during  the  reverse-engineering  of  IMCSRS  were  helpful  in  un¬ 
derstanding  how  the  processes  within  the  current  COBOL  version  of  IMCSRS  interacted, 
but  if  we  wished  to  take  advantage  of  a  structured  methodology  within  the  new  system,  it 
would  be  necessary  to  come  up  with  DFDs  for  the  new  design. 

We  needed  to  begin  our  analysis  by  determining  the  overall  context  of  the  new  system. 
The  context  of  the  system  basically  describes  how  the  system  interfaces  with  the  real 
world;  it  outlines  the  boundary  between  the  outside  world  and  the  internal  functions  of 
the  system.  The  context  diagram  for  the  system  is  a  very  simple  diagram  depicting  the 
external  processes  that  interact  with  IMCSRS  as  sources/sinks.  On  this  diagram,  we  are 
only  concerned  with  3  interfaces:  1)  Operating  system,  2)  Data  entry  operator,  and  3) 
Reporting  units. 

—  The  operating  system  communicates  with  IMCSRS  by  not  only  controlling  the  program 
execution,  but  also  by  supplying  the  UIC_MASTER  and  ECCLJN_MASTER  files  as  input. 
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These  files  are  updated  by  IMCSRS. 


—  The  data  entry  operator  is  the  person  or  persons  within  the  DOL  (Directorate  of  Logis¬ 
tics)  that  supply  the  information  from  the  DD  2406  used  to  generate  the  2406  transaction 
file.  On  the  current  version  of  IMCSRS  the  information  exists  as  card  input  that  the  data 
operators  run  through  the  system  in  batch  mode.  In  the  new  system,  the  2406  will  be 
entered  through  a  menu-driven  screen  interface.  The  operator  also  enters  any  requests 
for  updating  the  ECCLJN_MASTER  and  UIC_MASTER  files 

—  The  reporting  units  include  the  installation,  division,  and  major  command  recipients  of 
the  output  reports.  MRSA,  FORSCOM,  and  TRANSCOM  are  part  of  the  group,  receiving 
their  information  via  AUTODIN. 


How  the  sources/sinks  receive  the  output  data  or  produce  the  input  data  is  not  important 
at  this  level  of  abstraction  during  the  analysis  of  the  system.  They  only  appear  on  the 
context  diagram  to  represent  the  external  view  of  IMCSRS. 


The  next  level  within  the  DFD  hierarchy,  level  0,  outlines  the  major  processes  that  take 
place  within  the  system.  IMCSRS  performs  4  different  functions: 


1.  Updates  the  UIC_MASTER  file 

2.  Updates  the  ECCLIN_MASTER  file 
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3.  Creates,  edits  the  2406_TRANS ACTION  file 

4.  Generates  output  reports 

The  process  bubbles  were  labeled  accordingly.  Data  flows  that  enter  a  process  bubble 
without  an  originating  process  are  considered  to  enter  the  diagram  from  one  level  higher 
in  the  hierarchy.  For  example,  the  UIC_TRANSACTIONS  data  flow  is  a  component  of 
information  obtained  from  the  data  entry  operator  at  the  context  diagram  level.  By  the 
same  token,  data  flows  that  have  no  termination  process  extend  to  the  parent  DFD.  The 
child  DFD  is  a  breakdown  of  the  inputs/outputs  from  its  corresponding  parent  process. 
All  data  flows  leading  away  from  the  GENERATE_2406_REPORTS  process  bubble  would 
appear  in  a  data  dictionary  as  components  of  the  IMCSRS_REPORTS  data  flow  entering 
the  REPORTING  UNITS  sink  on  the  context  diagram. 


The  files  that  are  being  used  at  this  level  are  represented  as  data  stores.  When  a  data 
flow  enters  or  leaves  a  data  store  and  is  not  labeled,  all  the  data  items  contained  in  the 
data  store  are  being  passed  as  one  unit.  The  data  flow  leading  from  the  UIC_MASTER 
data  store  to  the  UPDATE_UIC_MASTER  passes  the  entire  UIC_MASTER_RECORD  for 
processing.  The  non-labeled  incoming  arrow  for  the  UIC_MASTER  store  indicates  that 
the  entire  updated  record  is  being  sent  to  the  master  file  for  storage. 

So  far,  we  are  still  only  identifying  the  processes  that  take  place  within  IMCSRS,  not  how 
they  execute  their  functions.  As  an  illustration  of  how  the  decomposition  of  the  processes 
takes  place,  look  at  the  level  0  DFD.  Process  bubble  1,  UPDATE_UIC_MASTER,  is  not 


-  34  - 


THE  JNSTALLATION  : 
INSTALLATION 


SAVE  INSTALLATION 


APPENDIX  B  (Data  Flow  Diagrams,  Structure  Charts) 


FROM 

ECCLIN 

MASTER 


EDIT  2406  TRANSACTION  FILE 


GENERATE  2406  REPORTS 


TRANSMISSION 

DATA 


a  sbs 


JPIN 


Ub  I  tUCUN_Ht<_;UHUb.<! 
No  tide 


PRINT_ECCUN_REPORT;2 
No  title 


r 


o  u 

O  UJ 
uj  S 


READ  ECCLIN 
MASTER  BY 
ECCUN 


PHINT_2406_REPORI.1 
No  bite 


s' I 

n  a  * 
O  UJ  rf 
Q  CC  O  . 


<n  io 

W  K  < 

uj  a: 

0  0  2 
O  a  < 
CC  Ul  s 
a  c  h 


9  p 
*  2;  a 
V  Q  uj 

l  O  Q  ff 


fi  O 

s  < 

Ui  ul  CC 
O  CC  t- 


5  tt 

a  g'2 

O  «  < 

U.  N  Q 


1EA0  2406  FILE 
ISING  UIC  AS 
IOEX 


Q30U3H  i 


</) 
o 
cr 
O 
o 
u j 
cc 


O 

cr 


o 

z 


0i mO  Ojipui  R|po«tS 


00140*  REPORT 
RECORDS 


